Directory number (DN) analysis and screening is a mandatory step in routing a call through a digital switch, such as a soft switch. DN screening determines whether a received DN belongs to the domain of a digital switch and thus determines how the switch will process the DN.
DN analysis typically includes the following steps: DN screening, which determines whether the directory number belongs to the domain serviced by the switch; digit analysis, which analyzes the received digits and processes the call based on the results of the analysis; and routing analysis, which determines the route to be taken by the call based on the results of the digit analysis. The DN screening step traditionally involves performing either a database query or a prefix pattern match.
The database approach typically involves storing in a database each number in the domain of the switch. During operation, a database access is made for each DN that is screened. Although this is an easy method to implement, the database access may incur significant processing overhead at every switch, due to the fact that a database access or query is performed for every DN; this additional overhead may degrade overall performance of the switch and may thus cause an unacceptable loss of capacity during peak traffic. The screening of a large number of DNs may become a significant bottleneck of a digital switch; in extreme cases, calls may be dropped or routed to other switches if a switch has exhausted its resources during the DN screening phase.
The prefix pattern match approach typically involves creating a table that stores a list of every prefix within the domain. For 10-digit numbering plans the prefix may be the most significant 7 digits of the DN, reflecting the fact that telephone numbers may be assigned to operators in blocks of 1,000 numbers. If operator A has been assigned a single block of 1,000 DNs, from 919.493.8000 through 919.493.8999, for example, a switch owned by operator A need only check only a single prefix (i.e., “9194938”) to determine if the number is within the assigned block. In this example, the table of prefixes contained within the domain would include just one entry: [9194938]. A prefix pattern match could be achieved with a single comparison. However, the prefix table for a switch with a domain containing telephone numbers 214.222.2000 through 310.999.9000 would contain 967,778 prefixes: [2142222, 2142223, 2142224 . . . , 3109997, 3109998, 3109999], where each prefix represents a block of 1,000 DNs. The prefix pattern match method also has some distinct disadvantages. First, this approach is not scalable to handle blocks of numbers with the same property that do not share a prefix. Although there are mathematic and other techniques, such as the use of parse trees, that avoid the necessity of performing the above-described prefix comparisons to perform a prefix pattern match, one problem is that for optimum speed, the entire table or tree should be in memory. Due to the size of the table and limitations on memory resources, however, it may be impossible or prohibitively costly to keep the entire table or tree in memory. Second, if a database is used to store prefixes rather than storing the full DN, although the prefix pattern match approach may reduce by a factor of 1000 the number of entries that must be stored and compared, that number may still be large enough to cause performance of the switch to suffer due to the overhead incurred by database access and processing. Third, if a parse tree is used to store prefixes, although the use of such a tree has the benefit of fast number lookup (at the expense of potentially enormous memory requirements, as mentioned above), the maintenance of parse trees—adding and deleting blocks of numbers—may be very resource intensive and thus costly, and may require multiple traversals of the entire tree. In situations where the numbers associated with the domain of a particular switch change relatively often, the additional overhead incurred to continuously maintain the tree may cause performance of the switch to suffer unacceptably.
Accordingly, in light of these disadvantages associated with database lookup and prefix pattern-matching methods of DN screening, there exists a need for a way to perform DN screening that is fast, uses minimal processing and memory resources, and is easily and quickly maintained.